AWS Elastic Disaster Recovery(DRS)を使ってレプリケートしたマシンを復元してみた

こんにちは、AWS事業本部の荒平(@0Air)です。
AWS Elastic Disaster Recovery(DRS)を触ってみたい季節の中、リカバリの挙動も確かめることにしました。
以下の記事の続編です。初期設定やレプリケートまでの手順は以下をお読みください。

構成図

本エントリの構成図です。点線部は前回記事を参照ください。
DR発動（リカバリジョブの起動）によって、対象リージョン内にEC2を作成し立ち上げます。

フェイルオーバー実行

今回はDR発動を想定し、リカバリドリル機能で復旧できるかどうか確認します。
「ドリル」は日本語では訓練の意味を持ちます。以下のドキュメント手順に沿って確認します。

対象のソースサーバが次に取るべきアクションを「ドリルを開始」になっていることを確認し、「リカバリドリルを開始」をクリックします。

最新のデータを使用するか、特定時点のスナップショットに復旧させることができます。
AWS DRSでは、複数サーバを一度に復旧させることができ、1つのジョブで100台のソースサーバが登録できます。
（参考：AWS Elastic Disaster Recovery エンドポイントとクォータ）

デフォルトでは、1時間以内であれば10分毎、24時間以内は1時間毎、7日以内は1日1回のバックアップが取得されます。
復元する時間を指定したら、「ドリルを開始」します。

リカバリジョブが開始され、AWS DRSのリージョンにElastic Disaster Recoveryによる、マシン変換用のConversion Serverがデプロイされます。
このコンバージョンサーバは、ブートローダの変更、ドライバの挿入、クラウドツールのインストールを行うようです。(参考)
AWS MGNの仕組みと同様かと思われます。

「リカバリジョブの履歴」または、実行後のバーより、ジョブの状態を表示することができます。

ジョブ画面では、開始・終了時刻とジョブ内容が確認できます。
今回の検証サーバは8GBのLinuxにて検証し、8分50秒でジョブが完了しました。

EC2の一覧画面にソースサーバの名称で表示され、「リカバリインスタンス」画面にも現れました。

EC2のNameタグはソースサーバのホスト名が自動付与されています。

なお、サーバ内部のホスト名は移行先ネットワークのものに変更されていました。
ソースサーバはc6i.largeだったのですが、c5.largeで起動してきました。これは、AWS DRS側で適切なサイジングが適用された影響と思われます。(念の為、ターゲットAZではc6iファミリーは提供されています)

$ hostnamectl
 Static hostname: ip-10-0-6-124.ap-northeast-1.compute.internal
       Icon name: computer-vm
         Chassis: vm 🖴
      Machine ID: ec28dc5f039d526027db7d9f2e6ad760
         Boot ID: 0c0d96a462b14b438fc47076da9b3276
  Virtualization: amazon
Operating System: Amazon Linux 2023
     CPE OS Name: cpe:2.3:o:amazon:amazon_linux:2023
          Kernel: Linux 6.1.72-96.166.amzn2023.x86_64
    Architecture: x86-64
 Hardware Vendor: Amazon EC2
  Hardware Model: c5.large
Firmware Version: 1.0

【参考】ソースサーバと通信できない際の挙動

前記事から1日環境を放置していたため、ソースサーバの電源を落としていました。
コンソールでの表示は「ラグ」や「停滞」と表示されます。
なお、ポイントインタイムリカバリは、正常に取得できたバックアップ時点での復旧が可能です。

EC2インスタンスは停止から起動したのみで、AWS Replication Agentの起動等は行っていないのですが、インスタンス起動後に自動で再同期されました。
ちなみに、ソースサーバを停止している間もElastic Disaster Recoveryの時間料金が発生するためご注意ください。

おわりに

AWS Elastic Disaster Recovery(DRS)によるリカバリを試しました。実際慣れればとても簡単にリカバリが実行できます。
今回は、ドリルという訓練用の機能を使いましたが、本番機能と同様に使えます。
また、AWS Application Migration Service (AWS MGN)と同じく、リカバリ後のpost-launch-actionが利用でき、リカバリ後に定義したアクションを実行することができます。

今回フェイルバック機能も試したかったのですが、AWS間のレプリケートではサポートしていないようでした。（以下参照：「Failback is only supported to non-AWS environments that can boot up from an ISO」）
オンプレや他クラウド間では可能なので、いずれ試してみたいと思います。

このエントリが誰かの助けになれば幸いです。

それでは、AWS事業本部 コンサルティング部の荒平(@0Air)がお送りしました！